I don't think this editor scales well enough. Each API function needs a wrapper of 10 lines (in total).
Could we perhaps bring this down using a lookup table? Example (untested):

local funcs = {
	-- [1] = getter, [2] = setter
	clouds = { "get_clouds", "set_clouds" },
	sky = {
		function(p) return p:get_sky(true); end,
		"set_sky"
	}
	-- ...
}

local function exec(player, func, ...)
	if type(func) == "string" then
		return player[func](player, ...)
	end
	if type(func) == "function" then
		return func(player, ...)
	end

	-- error message
	return nil
end


-- in core.register_chatcommand : skim through the table

		local def = funcs[param]
		if def then
			return editor_formspec_create(name, def)
		end
		return false, "Unknown command"

Verbose descriptions are not needed. The developers who would use this tool do know what kind of functions we're testing.

Personally I don't need this. I'd either write my own little test mods, or drag something simpler, but more powerful in:

A simple /lua chatcommand and/or a formspec where you can run Lua code, additionally ideally with an environment which contains a me = <player ref of executing player> variable, and pretty-printing of return values.

Then you can just do something like me:set_lighting{...} and observe the effect or me:get_lighting() and inspect the return value.

A simple /lua chatcommand and/or a formspec where you can run Lua code, additionally ideally with an environment which contains a me = <player ref of executing player> variable, and pretty-printing of return values.

This is what I'm using (yes, a fork of a fork, modified so that it is more usable, ignoring code quality. take it as inspiration for features or so): https://github.com/Desour/luacmd

But there's no reason why we can't have both.

A node with a formspec where you can store code snippets would also be nice. And maybe such that you can easily add buttons, so PRs and issues can for reproduction just provide a configuration for this node.

@appgurueu
Yes, I know about the/lua command. I often use it, make a typo error, and lose a few minutes of my time by checking if it does not work or if I made a typo error.

For example, if I want to check all player-specific graphic settings before release, I have to write many lines of /lua commands and I am sure, I make many typo errors.

With player_editor I need only a few commands, and form spec will lead me.

It definitely can be done as a separate mod. I created PR because I find it potentially helpful for Luanti testing purposes.
It looks to me similar to other formspec-based editors included in devtest. Every form spec editor can be removed from devtest and replaced with \lua command.

But if other code devs do not see the benefits of this, let's close this PR.

I am not opposed to this PR. I was just saying that I don't find it very useful personally. I agree with Desour that "there's no reason why we can't have both". So feel free to move forward. I may add a /lua chatcommand to devtest in a separate PR at some point.

It definitely can be done as a separate mod.

I think you might have misunderstood me. I just said that I often test features added in PRs via a "testbed" mod of mine, not that this has no place in devtest.

@SmallJoker Wrappers reworked to the table.